What Happens in a Simulation?

Process Navigator uses a token passing algorithm modelled on the theory of a Petri Net.

When the simulation begins, a token is associated with the triggering deliverable, and a 'pass' is made where the token is moved (and replicated as necessary) to each of the triggering deliverable's outgoing connectors. On the 2nd pass, the token is then moved from each Connector to the object they are connected to.

When a token arrives at an object, the object's frequency of occurrence is incremented.

When a token arrives at a branching object, i.e. only one of the outgoing connectors is executed, not all of them, Process Navigator randomly selects a connector based on the probabilities that are specified on the connector's text (or a computed probability of equal chance for connectors with no probability specified). The token is then passed to just that single connector.

When a token arrives at an Activity that has a drill-down, the token is passed to corresponding child input deliverables on the drill-down map. It is therefore important that orphan deliverables are properly resolved before using simulation. When a token arrives at the end of the drill-down map, it is then passed upwards to the outgoing connectors of the Activity where the drill-down occurred.

When a token arrives at an end point, it is destroyed.

When there are no tokens left, the simulation run is complete, and the next run begins.

If a token arrives at an object it has previously encountered, and the probability of doing so is 1, then the model contains an infinite loop and an error condition is reported.

If the total number of token passes exceeds the Maximim Number of Token Passes per Simulation Run Before Stop value specified on the Process Metrics tab in the Options dialog box, then the simulation stops.

Some Useful Expressions

When a token passes from one object to another, the passing object is said to have 'fired' its token.

A triggering deliverable is said to be a 'source', and an end point is said to be a 'sink'.

A 'pathway' is a unique sequence of objects from a source to a sink. Therefore, a process with a loop back will have different pathways corresponding to each iteration of the loop (potentially infinitely many).

A 'merge point' is any object with incoming connectors from 2 or more other objects.

An 'AND gate' is a merge point that fires when all of its incoming connectors have fired.

An 'OR gate' is a merge point that fires when any of its incoming connectors have fired.

Token Accumulation and Merging

Consider the process flow below:

In the token passing algorithm, because there are fewer objects on the upper branch, the token on the upper branch will arrive at the last Activity 4 passes before the token travelling along the lower branch.

How is this to be interpreted? There are 2 possibilities:

1. The final Activity occurs once because it is a 'stop and synchronise' point (an AND gate) for both Pathways, OR
2. The final Activity occurs twice, once for each Pathway

The interpretation is important, because the simulated costs of the E2EP will be different depending on the assumption that is made. Furthermore, in the 2nd case above, were the process map extended further to the right, every further object would also be counted twice.

In Triaster, the first assumption is made by default, and in the algorithm, when the first token arrives at the final Activity, the final Activity does not fire. It waits for the arrival of the 2nd token, and then fires (and if there were more than 2 incoming connectors, it would wait for the arrival of a token from every incoming connector). The firing object only fires one token irrespective of how many tokens arrived.

Sometimes, an Activity will be waiting for an incoming token to arrive, but in fact there is no token anywhere on the incoming pathway.

Consider the example below in which the branches are now mutually exclusive:

In this flow, the token only goes along 1 branch, and when it arrives at the final Activity there is no other token in the system.

With Process Navigator, tokens always accumulate and an object fires when:

• all of its incoming connectors have fired, OR
• there are no tokens remaining in the system.

In Triaster therefore, all objects are AND gates by default. They become OR gates if and only if the simulation would otherwise stop. There is no technique in Triaster to force an object to be an OR gate by default. The reason for this is that in most cases an OR gate is not intended, and the model automatically converts an object to an OR gate for those objects that really are OR gates.